PATENTS 

IN THE UNITED STATES PATENT AND TRADEMARK OFFICE 
In re application of 

Linghsiao WANG Group Art Unit: 2151 

Application No. 10/729,804 Examiner G. Madamba 

Filed: December 5, 2003 

For: CLASS-BASED RATE CONTROL USING A MULTI-THRESHOLD LEAKY BUCKET 
RESPONSE 

Commissioner for Patents 

P.O. Box 1450 

Alexandria, VA 22313-1450 

Sir: 

In response to the Office Action mailed July 9, 2007, applicant respectfully requests 
reconsideration of the rejection of claims 1-27. 

The Examiner has rejected claims 1-27 under 25 U.S.C. §103(a) as being unpatentable 
over U.S. Publication 2003/0035374 by Carter in view of U.S. Patent 7,126,913 issued to Patel. 

The claims of the present application are directed to apparatus and methods for effecting 
rate control of egress traffic from an edge network node and of ingress traffic to an edge network 
node. A leaky bucket is used having multiple threshold level registers. Broadly, when a packet 
is received, a traffic class of the packet is checked, and a determination on whether to suppress 
transmission (in the case of egress traffic) is made based on the traffic class of the packet and on 
the occupancy of the leaky bucket as indicated by the multiple threshold level registers and by a 
current token availability of the bucket. A similar decision is made for ingress traffic using 
similar considerations, namely the traffic class of the packet and the occupancy of the leaky 
bucket as indicated by the current token availability and the multiple threshold level registers, 
except that a probability discard register associated with each traffic class is also considered, and 
that the packets are discarded rather than suppressed. The claimed invention allows a single 
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leaky bucket to be used for traffic of multiple traffic classes, while preferentially allowing traffic 
of certain classes to be transmitted when resources are limited. 

Carter is directed to a method of reducing traffic congestion between routers by 
determining a statistical bit rate over sequential intervals. Based on the sampling of actual bit 
rates and a statistical estimation of projected congestion, the output bit rate of a buffer is 
adjusted. Carter discusses leaky buckets only twice, towards the very end of the description of 
the method (paragraphs 84 and 86), and only in very general terms. The objective of Carter is 
clearly not to provide a leaky bucket routine for managing traffic flow rates. 

Patel is directed to a method of managing transmission resources at a node, and in 
particular for determining whether to transmit packets through a node based on other traffic and 
available resources. Patel teaches a method of using leaky buckets to achieve this, including a 
new type of leaky bucket and a new way of defining tokens to be used in relation to the bucket. 
The bucket and the tokens are multi-dimensional. As the simplest example (Figures 3 to 8e) the 
token for a packet is two dimensional, with one dimension indicating the time resources required 
for transmitting a packet and with one dimension indicating the power resources required for 
transmitting a packet (Figures 5, 8a). The bucket is also two dimensional (Figure 4). When a 
packet is to be transmitted, the method determines whether there is sufficient two dimensional 
token-space within the bucket to accommodate the packet (Figures 8b-8e; element 1 14 of Figure 
7 and description at column 9 lines 14-23). Patel also provides an example of three dimensional 
tokens and buckets, in which geographic information (sectors and interference) is used as the 
third dimension. However, nowhere does Patel teach the use of traffic class in a determination of 
whether there are sufficient resources to transmit a packet, and certainly does not teach the use of 
a single bucket with multiple threshold level registers for determining whether to transmit a 
packet based on the traffic class of the packet and on the current occupancy of the bucket as 
indicated by the multiple threshold registers. In fact, Patel strongly suggests the use of multiple 
buckets in order to handle packets of different traffic classes: "To support multiple service levels, 
multi-media, and customer groups, packet flows in the mobile gateway 20 may be organized into 
a plurality of discrete groups. In this case, a separate set of multiple dimension token buckets 44 
maybe used to police and control flows in each group." (column 7 lines 10-14). 
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Neither Carter nor Patel teach or suggest the present claimed invention. The differences 
between the present claims and the teachings of Carter and Patel will be seen more clearly by 
considering the specific elements of the present claims. 

Claim 1 is directed to an egress rate controller which includes a packet transmission 
suppression controller. The packet transmission suppression controller selectively suppresses 
transmission of a packet based on a current token availability level being within a token 
availability region specifying transmission suppression of packets of the traffic class of the 
packet. This is a feature not taught or suggested by either Carter or Patel. The Examiner has 
cited extensively from Patel as teaching this feature. However, nowhere does Patel teach or 
suggest this feature. Figures 3 and 4 show a two-dimensional bucket, but neither of the two 
dimensions is related to the traffic class of the packet. Figure 5 shows a generic two dimensional 
token to be associated with a packet, but neither of the dimensions is related to the traffic class of 
the packet. Figure 7 is a flowchart of a method which considers the occupancy of the bucket 
when determining whether to transmit a packet (steps 1 14 and 134), but the accompanying 
description at column 9 lines 14-20 clearly explains that this determination is based on whether 
the bucket indicates that there is sufficient power level and time available to accommodate the 
two dimensional token of the packet, and makes no reference at all to consideration of the traffic 
class of the packet. Figures 8a-e show an example of the application of the method of Figure 7 
with four example packets and associated tokens, but nowhere considers the traffic class of the 
packets. Figure 1 1 is similar to Figure 7 but takes into account the geographic information in the 
example of three dimensional tokens and bucket, but makes no reference to traffic class. Figure 
13 shows an example implementation for three dimensional tokens and buckets, but makes no 
reference to the traffic class of packets 

Column 7 lines 42-53 describes the addition and removal of two dimensional tokens from 
the two dimensional bucket, but makes no reference to the traffic class of packets. Column 8 
lines 21-35 describes the two dimensional token of Figure 5, but makes no mention of the traffic 
class of the packets, and in fact specifies that the two dimensions of the token are power 
requirement of transmission of the packet and duration of impact on the system of transmission 
of the packet. Column 8 line 60 to column 9 line 60 describes the flowchart of Figure 7, but 
makes no mention of the traffic class of a packet, let alone selectively suppressing transmission 
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of a packet based on a current token availability level being within a token availability region 
specifying transmission suppression of packets of the traffic class of the packet. The only 
consideration used in deciding whether to transmit a packet are whether the two dimensional 
token associated with a packet fits within the two dimensional bucket of available tokens 
(column 9 lines 14-20). 

In summary, neither Carter nor Patel teach the use of multiple token availability threshold 
registers to define token availability regions, and determining whether to suppress transmission 
of a packet based on the current token availability level (i.e. current occupancy of the bucket) 
being within a token availability region which specifies transmission suppression of packets of 
the traffic class of the packet. 

Claims 2-6 are dependent on claim 1 and include the same limitations discussed above. 
Claims 7 and 8 comprise the egress rate controller of claim 1 and include the same limitations 
discussed above. Since the Examiner has not shown where every element of claims 1-8 are 
taught or suggested by Carter or Patel, either alone or in combination, the Applicant respectfully 
submits that a prima facie case of obviousness has not been established against claims 1-8. 

The Examiner has not discussed claims 9, 10, and 12-15. Furthermore claim 9, on which 
claims 10 and 12-15 are dependent, includes some of the limitations of claim 1, in particular the 
limitations discussed above. Since the Examiner has not shown where Carter or Patel, either 
alone or in combination, teach or suggest every element of the claims, the Applicant respectfully 
submits that a prima facie case of obviousness has not been established against claims 9, 10, and 
12-15. 

Regarding claim 1 1, the Examiner has stated that the claim recites the same limitations as 
claim 4 and is distinguished only by its statutory category and is thus rejected on the same basis. 
The Applicant assumes that this is a clerical error on the part of the Examiner, since claim 1 1 is 
dependent on claim 9 which includes limitations not found in claim 4. Since the Examiner has 
not shown where every element of claim 11, including those of claim 9, are taught or suggested 
by Carter or Patel either alone or in combination, the Applicant respectfully submits that a prima 
facie case of obviousness has not been established against claim 11. 
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Claim 16 is directed to a method of effecting egress rate control. The method includes 
the limitation of suppressing packet transmission of a packet of a particular traffic class when 
current token availability level of a leaky bucket is between two token availability threshold 
levels. The Examiner has not shown where this feature of claim 16 is taught by Carter or Patel. 
As discussed above, neither Carter nor Patel teach consideration of the traffic class of a packet 
and the current occupancy of a leaky bucket in determining whether to suppress transmission of 
the packet. Furthermore, neither Carter nor Patel teaches or suggests a leaky bucket having 
multiple token availability thresholds. The Examiner has indicated (when discussing claim 1) 
that this element is taught by Patel at Figures 3, 4, and 8a-e. However, these figures (and the rest 
of Patel) teach two dimensional tokens and buckets. The purpose of the two dimensions is to see 
whether a two dimensional token of a packet, which reflects the power usage and time 
requirements of transmitting the packet, fit within the available two dimensional bucket. If the 
token fits anywhere within the bucket, then there is sufficient power and time to transmit the 
packet. Patel does not teach multiple availability threshold levels, and a packet is transmitted 
regardless of the actual occupancy of the bucket as long as the token of the packet fits somewhere 
within the bucket. This is not the same as determining whether an occupancy is between two 
thresholds, and only transmitting a packet based on its traffic class and on whether the occupancy 
of the bucket is between two availability thresholds. 

Claims 17-23 are dependent on claim 16 and include the same limitations discussed 
above. Because the Examiner has not shown where Carter and Patel, either alone or in 
combination, teach or suggest every element of the claims, the Applicant respectfully submits 
that a prima facie case of obviousness has not been established against claims 16-23. 

The Examiner has not discussed claims 24-27. Furthermore, claim 24 includes some of 
the limitations of claim 16, in particular the limitations discussed above. Claims 25-27 are 
dependent on claim 24 and include the same limitations discussed above. Since the Examiner 
has not shown where Carter or Patel, either alone or in combination, teach or suggest every 
element of the claims, the Applicant respectfully submits that a prima facie case of obviousness 
has not been established against claims 24-27. 
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Furthermore, the Applicant respectfully submits that the Examiner has not provided 
reasons why a person of ordinary skill in the art would be motivated to combine the method of 
Patel with the system of Carter. Throughout the Office Action, the Examiner has merely stated 
that the motivation would be for "providing a method and system for managing transmission 
resources in a wireless communications network architecture" (pages 4, 6, 9). This is simply the 
sentence of the Technical Field of the Invention of Patel (column 1 lines 32-33), and provides no 
problem which a person of ordinary skill in the art would be trying to solve, and provides no 
reason why a person of ordinary skill in the art would consider combining Patel and Carter in 
order to solve such a problem. Since the Examiner has not shown motivation to combine the 
teachings of Patel and Carter, the Applicant respectfully submits that a prima facie case of 
obviousness has not been established against claims 1-27 with respect to Carter and Patel. 

The Examiner has also rejected claims 9-10, 12-15, and 24-27 under 35 U.S.C. §103(a) as 
being unpatentable over Carter, Patel, and U.S. Patent 6,987,732 issued to Gracon. Gracon 
teaches a packet scheduler for multi-protocol traffic. A congestion manager considers an 
instantaneous queue size of a connection to determine whether to drop a packet received on the 
connection. 

Claim 9 is directed to an ingress rate controller which includes a packet acceptance 
controller. The packet acceptance controller selectively randomly discards packets based on a 
current token availability level being within a token availability region specifying random packet 
discard of packets of the traffic class of the packet. This is a feature not taught by Carter, Patel, 
or Gracon. This feature is discussed in relation to Carter and Patel above with reference to claim 
1. The Examiner states that Gracon teaches this feature at column 7 lines 49-53. This passage 
discusses a random early detection process, in which an average queue size of connections on 
which packets are arriving is compared with a minimum threshold and a maximum threshold. If 
the average queue size lies between the minimum threshold and the maximum threshold, then a 
packet drop probability is calculated, and the packet is randomly dropped based on the calculated 
packet drop probability (column 7 lines 30-53). While this passage teaches random discard of 
packets under certain circumstances, nowhere is the traffic class of the packet used as a basis for 
the determination of whether to perform the random determination. By using multiple threshold 
levels to define multiple token availability regions, the ingress rate controller of claim 9 uses the 
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traffic class of a packet and the current occupancy level of the leaky bucket to determine whether 
to randomly drop a packet. This is not a feature taught by Gracon. 

Claims 10 and 12-15 are dependent on claim 9 and include the same limitations. Since 
the Examiner has not shown where every element of the claims is taught or suggested by Carter, 
Patel, or Garcon, either alone or in combination, the Applicant respectfully submits that a prima 
facie case of obviousness has not been established against claims 9, 10, and 12-15. 

Claim 24 is directed to a method of effecting ingress rate control, and includes the 
limitation of selectively randomly discarding packets of a particular traffic class when a current 
token availability level of a leaky bucket tracking packets is between two token availability 
threshold levels of a plurality of token availability threshold levels. The Examiner has not shown 
where this feature is taught by Carter, Patel, or Garcon. At page 16 of the Office Action the 
Examiner appears to address the elements of claim 24, but instead quotes element (d) of claim 9. 
These are different elements. In addition, the Examiner has cited column 7 line 28 to column 8 
line 12 of Gracon as teaching this element. This passage does teach the use of multiple 
thresholds with which an instantaneous queue size of a connection is compared. Depending on 
how the queue size compares with the various thresholds, packets of different colors are dropped, 
some randomly. However, these colors are not based on traffic class , but rather are assigned to a 
packet based on the compliance of the packet and connection with the scheduling of the policer. 
Gracon requires a separate and quite complicated algorithm to be performed ahead of time in 
order to assign a color to a packet (column 4 line 60 to column 7 line 27). While the congestion 
manager randomly drops some packets based on threshold levels, these threshold levels are 
defined in terms of the compliance of packet arrival times, and are not based on the traffic class 
of the packets. 

Claims 25-27 are dependent on claim 24 and include the same limitations discussed 
above. Since the Examiner has not shown where every element of the claims is taught or 
suggested by Carter, Patel, or Gracon, either alone or in combination, the Applicant respectfully 
submits that a prima facie case of obviousness has not been established against claims 24-27. 

Furthermore, the Applicant respectfully submits that the Examiner has not provided 
reasons why a person of ordinary skill in the art would be motivated to combine the methods of 
Carter, Patel, and Garcon. Throughout the Office Action, the Examiner has merely stated that 
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the motivation for combining Carter and Patel would be for "providing a method and system for 
managing transmission resources in a wireless communications network architecture" (pages 11, 
13, 15, 17, 20), and the motivation for combining Carter and Patel with Garcon would be for 
"providing an apparatus that is programmable to accommodate existing protocols and to 
anticipate any future protocols, as well as to efficiently schedule packets in a broadband data 
stream" (pages 12, 16, 18, 21). These are simply the sentence of the Technical Field of the 
Invention of Patel (column 1 lines 32-33), and the sentences at the end of the Background of the 
Invention of Garcon (column 2 lines 11-15). These sentences provide no problem which a 
person of ordinary skill in the art would be trying to solve, and provide no reason why a person 
of ordinary skill in the art would consider combining Patel and Carter or Patel and Carter and 
Garcon in order to solve such a problem. Since the Examiner has not shown motivation to 
combine the teachings of Patel, Carter, and Garcon, the Applicant respectfully submits that a 
prima facie case of obviousness has not been established against claims 9, 10, 12-15, and 24-27. 

In view of the foregoing, it is believed that the claims at present on file are in condition 
for allowance. Reconsideration and action to this end is respectfully requested. 



Respectfully submitted, 




_, 2007 



Lawrence H Laubscher, Jr. 
RegMratioji No. 28,233 J 
Laubscher & LaubscheYrPC 
1160 Spa Road, Suite 2B 
Annapolis, MD 21403 
Telephone: (410) 280-6608 
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